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ABSTRACT 


Articulating  user  requirements  is  arguably  one  of  the  most  difficult  and  yet  critical  challenges  in 
any  Information  System  Project.  Within  the  British  Army,  the  Directorate  of  Command  and 
Battlespace  Management  (Army)  has  been  developing  its  user  requirement  methodology  and 
practice  over  the  last  few  years  and  now  uses  the  Ministry  of  Defence  Architectural  Framework 
(MODAF)  as  a  comer  stone  of  its  approach.  This  paper  explains  the  methodology  that  has  been 
developed  to  overcome  some  of  the  difficulties  associated  with  user  requirement  engineering  for 
Command  and  Battlespace  Management  IS.  The  specific  difficulties  are: 

•  How  to  bridge  the  gap  between  users  who  may  not  know  what  they  want  and  industry  who 
may  not  understand  the  intricacies  of  the  military  business  to  be  supported. 

•  How  to  articulate  URs  in  a  manner  concise  and  digestible  enough  for  users  to  review 
effectively,  yet  comprehensive  enough  for  industry  to  fully  understand  the  requirement  and 
the  military  business  effected  by  the  system. 

•  How  to  ensure  a  User  Requirement  Document  (URD)  is  consistent  and  coherent  with  URDs 
for  other  IS  within  the  System  of  Systems. 

The  approach  taken  revolves  around  use  of  the  MODAF  framework,  instantiated  using  the  MooD 
Transformation  Tool  Set. 
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DEVELOPING  USER  REQUIREMENTS  USING  THE  MOD  ARCHITECHTURAL 
FRAMEWORK  (MODAF! 

INTRODUCTION 

1.  User  Requirements  (URs)  for  Information  System  Projects  should  convey  the  requirements 
of  military  business  in  such  a  way  that  all  parties  (users/customers  and  suppliers)  have  a  clear, 
unambiguous,  and  common  understanding  of  what  is  required.  Information  systems  must  be 
designed  to  support  military  processes;  either  current  processes  or  new  processes  developed  as  a 
result  of  the  IS  being  introduced.  Therefore  understanding  and  communicating  what  the  business 
wants  to  achieve,  and  how  it  intends  to  use  information  (the  military  processes)  to  achieve  that  end, 
is  fundamental  to  procuring  an  information  system  that  contributes  to  operational  capability  in  the 
desired  manner. 

2.  Text  based  descriptions  of  URs  generally  fail  to  convey,  on  their  own,  the  full  military  need: 
they  are  either  too  brief,  leaving  room  for  assumption  and  hence  misinterpretation,  or  are  too 
cumbersome  for  a  user  to  check  that  they  accurately  convey  the  intended  requirement.  The  use  of 
graphical  models  to  derive  and  augment  URs,  adds  both  detail  and  ease  of  understanding.  The 
nascent  MOD  Architectural  Framework  (MODAF)1  is  a  description  of  a  framework  for  breaking 
down  a  complex  mix  of  ideas  such  as  objectives,  processes,  organisations  and  technical  resources 
into  easily  digestible  graphical  representations,  which  can  be  linked  together  to  describe  an  entire 
military  enterprise.  Models  developed  in  a  MODAF  compliant  manner  combine  (and  are  referred 
to  collectively  as  an  architecture)  to  describe  an  enterprise  of  interest  to  the  target  audience  in  a 
concise  yet  comprehensive  manner.  MODAF  compliant  architectures  compliment  text  based  URs 
and  are  used  to  inform  and  support  traditional  User  Requirement  Documents  (URD).  When 
combined,  the  URD  should  explicitly  state  the  requirement,  and  the  architecture  should  provide  the 
understanding  and  context  required  to  minimise2  ambiguity  and  achieve  common  understanding 
between  the  customers  and  suppliers. 

3.  Information  Systems  offer  opportunities  to  improve  military  processes  as  well  as  performing 
existing  process  faster  and  more  easily.  However,  users  often  struggle  to  specify  more  than  an 
automation  of  existing  process  and  practices  using  text  based  URs  alone.  It  is  this  phenomenon  that 
led  to  the  Canadian  Digitisation  experience  -  as  soon  as  users  were  given  an  IS  system,  their 
experience  with  it  changed  their  requirements.  The  rich  yet  concise  nature  of  MODAF  models  acts 
as  a  lingua  franca  and  provides  improved  understanding  that  facilitates  meaningful  discussions 
between  users  and  contractors  that  enable  each  evolution  of  an  information  system  to  make  greater 
progress  than  it  otherwise  might. 


AIM 


4.  The  aim  of  this  paper  is  to  outline  how  use  of  graphical  architectures  based  on  MODAF 
improves  the  development  and  articulation  of  User  Requirement  Documents  for  information 
systems.  The  UK  MoD’s  Best  Practice  Guide  to  Digitisation  User  Requirements3  gives  more 
detailed  guidance  on  developing  user  requirements,  and  is  aimed  at  those  actually  writing  URDs. 


1  MODAF  is  a  standard  being  developed  from  the  American  DoDAF,  sponsored  by  CM(IS)  and  project  managed  by  DEC  CCII.  The  main  additions 
to  DoDAF  are  the  Strategic  and  Acquisition  Views.  Formal  release  is  expected  to  be  June  2005. 

2  Eliminating  ambiguity  entirely  is  an  aspiration  rather  than  an  achievable  end  state,  just  as  achieving  100%  safety  is  an  unachievable  aspiration. 

3  Best  Practice  Guide  to  Digitisation  User  Requirements.  D  Info(A)/695/l 0/Info  Coherence 
Issue  1.0-28  Oct  03. 
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This  paper  does  give  an  outline  of  the  elements  of  MODAF  most  relevant  to  user  requirements4,  but 
the  emphasis  is  on  explaining  what  each  MODAF  view  contributes  to  the  requirements  process 
rather  than  providing  a  definitive  guide  to  MODAF  itself. 

LAYOUT  OF  THE  PAPER 


5.  This  paper  gives  an  overview  of  the  user  requirements  derivation  process  supported  by 
MODAF,  which  is  intended  to  orientate  the  reader.  This  is  followed  by  a  brief  description  of  the 
architectural  framework  with  emphasis  on  the  purpose  and  content  of  the  different  MODAF  views 
in  relation  to  deriving  URs.  The  Section  on  Construction  of  the  URD  explains  the  elements  of  a 
digitisation  URD  and  which  MODAF  views  inform  them.  The  process  is  still  evolving,  and  so  the 
last  Section  before  the  Summary  and  Conclusion  describe  the  known  areas  for  future  development. 

OVERVIEW  OF  THE  USER  REQUIREMENTS  DERIVATION  PROCESS  SUPPORTED 

BY  MODAF 


6.  The  process  of  deriving  user  requirements  is  iterative,  each  step  will  inform  both  the 
previous  and  subsequent  steps.  In  outline  the  process  is: 

a.  Identify  the  capability  requirement  or  gap,  this  could  be  an  end  state  or  a  stated 
deliverable. 

b.  Scope  the  boundary  of  the  issue  and  understand  the  capabilities  involved. 

c.  Understand  the  military  business  'As  Is',  using  models  as  appropriate  to  assist. 

d.  Determine  what  improvements  to  the  business  are  desired. 

e.  Develop  models  that  describe  the  military  business  as  it  is  'To  Be'. 

f.  Construct  the  URD  to  articulate  the  requirements  for  the  future  military  business 
need. 

IDENTIFY  CAPABILITY  REQUIREMENT 

7.  The  capability  need  or  gap  is  identified  and  articulated  using  MODAF  Strategic  Views 
(StV).  Capability  is  expressed  without  identifying  a  particular  application  or  new  system  as  the 
solution  to  meet  the  gap.  For  example  the  Joint  Force  HQ  and  Component  Commands5  have  a 
capability  gap  in  that  they  require,  but  do  not  have,  a  single  view  of  the  Joint  Force  Combat  Service 
Support  assets  and  resources. 

8.  Under  SMART  procurement,  identification  of  capability  gaps  and  initiating  projects  to  fill 
them  is  the  responsibility  of  the  DEC6.  The  process  used  by  this  organisation  to  articulate  URs 
does  not  normally  begin  until  the  DEC  has  identified  the  capability  gap.  In  this  case  Strategic 
Views  are  used  to  improve  the  Customer7  2  understanding  of  capability  as  it  is  expressed  by  the 


4  Some  views  in  MODAF  that  are  of  more  relevance  to  the  Developers  of  systems  and  the  Integration  Authority/DCS  A  who  have  to  maintain  a 
system  of  systems  understanding. 

5  Land,  Fleet  and  Air  Component  Commands. 

6  The  Directorate  of  Equipment  Capability  (DEC)  are  responsible  managing  the  total  equipment  capability.  Despite  SMART  procurement,  other 
organisations  often  perform  this  process  as  well.  For  example  the  DLO  have  previously  sponsored  their  own  projects,  with  capability  requirements 
being  identified  by  the  DLO  Business  Change  Teams. 

7  Customer  2  provides  the  expert  guidance  on  military  business  (customer  2  core  leader)  and  receives  and  manages  the  equipment  in  service  (pivotal 
manager). 
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Centre.  It  is  also  believed  that  the  Strategic  Views  defined  by  MODAF  should  be  used  to  aid  the 
DEC  during  the  capability  audits  and  help  them  prioritise  and  group  identified  gaps  into  projects. 

SCOPE  BOUNDARY  AND  UNDERSTAND  CAPABILITY 

9.  The  main  aim  of  this  stage  is  to  gain  a  clear  understanding  of  the  high-level  military 
objectives  to  be  supported.  The  purpose  of  any  IS  project  should  be  to  improve  the  delivery  of 
military  capability  and  therefore  the  project  must  be  focused  on  how  that  improvement  is  to  be 
achieved.  It  clearly  follows,  that  an  information  system  developed  from  a  poor  understanding  of 
capability  is  unlikely  to  result  in  capability  improvement.  Numerous  academic  studies  cite  a  poor 
understanding  of  the  business  objectives  systems  were  intended  to  improve  as  one  of  the  main 
causes  of  IS  project  failure. 

10.  The  understanding  gained  about  the  capability  areas  of  interest  can  then  be  used  to  define 
the  boundaries  of  the  military  enterprise  that  must  be  fully  understood  in  order  to  develop  the  user 
requirements  for  a  particular  project  or  IS.  For  example,  the  capability  gap  identified  in  the  JFHQ 
and  Component  Commands  is  understood  in  terms  of  how  gaining  a  single  view  of  CSS  contributes 
to,  and  affects  the  delivery  of  military  capability.  Having  understood  the  capability,  the  boundaries 
are  identified  and  agreed  as  extending  back  to  the  DLO8  and  forward  to  Brigade  Supply  Area  assets, 
as  they  impact  on  the  target  organisation’s  ability  to  deliver  the  required  capability. 

UNDERSTAND  THE  ‘AS  IS’ 

1 1 .  Thoroughly  understanding  how  military  capability  is  currently  delivered,  enhances 
individuals  ability  to  design  sensible  improvements  for  future  delivery.  You  cannot  plan  a  journey 
from  A  to  B  if  you  do  not  know  where  A  is.  In  particular,  it  is  necessary  to  understand  the  many 
and  varied  relationships  between  processes,  resources  and  military  objectives  in  order  to  ensure 
changes  achieve  the  desired  effects,  and  avoid  unintended  consequences. 

12.  Models  are  developed  to  provide  the  understanding  necessary  to  decide  how  military 
business  should  be  changed  in  order  to  achieve  the  desired  outcome.  The  modelling  activity  must 
be  carefully  considered  to  avoid  nugatory  work  (detailing  processes  to  be  made  obsolete  by  the  new 
system),  whilst  gaining  sufficient  shared  understanding  of  the  current  situation  to  discuss  and 
design  the  desired  future  situation. 

13.  The  level  of  ‘As  Is’  modelling  will  vary  considerably  on  any  given  project,  but  maximum 
use  of  existing  work  must  be  made  to  minimise  work  and  avoid  wasting  the  time  of  the  user 
community.  It  is  recommended  that  all  modelling  work  is  held  in  an  MOD  Architecture 
Repository,  and  that  where  appropriate  architectures  are  used  to  inform  tactics  and  doctrine 
publications  in  order  to  achieve  an  efficient  maintenance  of  the  corporate  knowledge  gained 
through  the  modelling  work:  Architectures  based  on  MODAF  provide  an  effective  means  of 
managing  and  communicating  knowledge  to  all  levels  of  an  enterprise  and  therefore  could  readily 
and  usefully  be  incorporated  into  Concepts,  Doctrine,  Tactics  Notes  and  SOPs. 

DETERMINE  THE  CHANGES  REQUIRED 

14.  Shared  knowledge  and  understanding  achieved  through  the  development  of  the  capability 
and  ‘As  Is’  models  enables  informed  decisions  to  be  made  about  what  is  required  in  the  future.  This 
should  include  changes  to  all  Lines  of  Development9  (LOD)  not  just  the  technical  application  or 
system  that  is  to  be  specified  in  the  equipment  element  of  the  URD. 


8  The  Defence  Logistic  Organisation  (DLO)  is  responsible  for  all  Logistics  in  the  MoD. 

9  The  MoD  breaks  capability  down  into  ‘Lines  of  Development’:  Finance,  Equipment,  Structures  and  Estates,  People,  Training  and  Concepts  & 
Doctrine. 
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MODEL  THE  ‘TO  BE’ 


15.  The  aim  of  the  ‘To  Be’  models  is  to  provide  the  understanding  required  to  derive  the  URD 
and  to  support  the  URD  by  providing  improved  understanding  of  what  is  required  and  how  it  is  to 
fit  into  the  business.  Appropriate  use  of  selected  MODAF  views  provides  a  far  richer,  yet  more 
readily  digestible  communication  of  the  requirements  and  their  context  than  a  text  based  URD  could 
ever  hope  to  achieve  on  its  own.  The  ‘To  Be’  models  should  not  attempt  to  impose  solutions  and 
care  must  be  taken  to  avoid  doing  so  inadvertently.  That  said,  it  is  quite  legitimate  to  express 
business  constraints,  for  example  an  application  aimed  at  a  battle  group  must  be  hosted  on  the 
Bowman  infrastructure. 

16.  Developing  the  ‘To  Be’  architecture  is  an  iterative  process  that  may  produce  a  number  of 
variants.  The  understanding  it  provides  will  lead  to  further  development  of  the  ideas  expressed 
within  the  architecture.  Development  of  the  architecture  should  not  be  seen  as  having  an  end  state; 
development  will  continue  long  after  the  URD  and  even  the  SRD  has  been  agreed.  Architectures 
developed  initially  for  deriving  and  articulating  URs  are  also  likely  to  become  an  integral  part  of 
experimentation  and  prototyping  activities. 

CONSTRUCT  THE  URD  AND  CONOPS/CONEMP 

17.  Despite  the  contention  that  MODAF  models  communicate  requirements  more  effectively 
than  a  traditional  URD,  the  URD  still  has  a  role  to  play.  A  URD  is  more  explicit  in  what  the  user 
requires  the  project  to  deliver,  providing  atomic  statements  against  which  a  project  can  deliver  and 
be  measured.  The  models  enhance  the  shared  understanding  and  are  intended  to  close  the  gaps 
between  ‘what  the  user  wanted’,  ‘what  the  user  asked  for’  and  ‘what  the  supplier  understood  the 
user  to  want’.  The  URD  and  the  models  are  complimentary,  not  mutually  exclusive. 

18.  Similar  arguments  apply  to  the  CONEMP  and  CONUSE  documents.  The  text-based 
documents  are  easily  accessible  in  that  they  can  be  read  from  beginning  to  end  with  out  need  of 
external  explanation.  The  graphical  models  contained  in  an  architecture  provide  a  logical  basis  on 
which  to  base  the  CONEMP  and  CONUSE,  and  provide  further  understanding  and  context. 

DESCRIPTION  AND  USE  OF  THE  FRAMEWORK 


19.  This  Section  describes  the  views  most  commonly  used  in  the  requirements  derivation 
process.  The  total  Architectural  Framework  contains  over  30  different  views,  split  into  strategic, 
operational,  system,  technical,  and  acquisition  categories.  MODAF  should  be  considered  as  a 
toolbox,  and  only  those  views  that  inform  the  issue  in  hand  should  be  used.  The  user  requirements 
derivation  process  makes  use  of  only  some  of  the  MODAF  views;  for  example,  the  Technical 
Views  are  not  currently  used  when  deriving  URs  (but  may  be  in  future  developments  to  improve  the 
use  of  Standards  in  URDs  -  See  paragraph  53). 

STRATEGIC  VIEWS 

20.  The  Strategic  Views  (StVs)  give  high-level  clarity  to  what  is  being  sought  by  the  MOD  and 
the  expected  time  frame.  They  allow  the  brigading  together  of  supporting  Operational  Views  and 
can  show  the  coupling  between  Capability  elements  and  supporting  System  clusters,  in  big  picture 
terms. 

21.  This  organisation  currently  uses  Soft  System  Methodology  (SSM)  based  conceptual  models 
to  investigate  and  articulate  capability  and  scope  the  boundaries.  The  MODAF  Project  Team  are 
developing  5  Strategic  Views  that  should  augment  D  CBM(A)’s  use  of  SSM  to  understand 
capability.  This  work  is  not  yet  complete  and  therefore  the  views  are  not  described  in  this  paper. 
The  StVs  can  be  presented  through  the  following  Products: 


5 


•  Capability  Vision  (StV-1):  Provides  an  outline  of  the  strategic  vision  for  a  capability  area 
over  a  particular  time  frame  and  informs  the  long-term  capability  planning  process. 

•  Capability  Functions  (StV-2):  Describes  functions  that  make  up  military  capability, 
including  attributes  and  metrics. 

•  Capability  Phasing  (StV-3):  Describes  how  capability  is  delivered  and  improved  over  time. 

•  Systems  of  Systems  Clusters  (StV-4):  Provides  a  means  of  analysing  the  main  dependencies 
between  capability  functions  and  identifies  logical  grouping  of  capabilities. 

•  Capability  to  Systems  Deployment  Mapping  (StV-5):  Uses  a  synthesis  of  information  from 
the  other  strategic  views  to  show  the  planned  capability  deployment  and  interconnection  by 
echelon/epoch,  providing  more  detailed  dependency  analyses  than  StV-3. 

22.  Use  of  Strategic  Views  in  the  ‘As  Is’  Models. 

a.  The  Strategic  views  are  used  to  their  full  extent  in  the  ‘As  Is’  models,  where 
understanding  the  military  objectives  is  paramount  as  discussed  in  paragraph  13.  A  lack  of 
common  shared  understanding  will  inevitably  lead  to  misconceptions  and  inappropriate 
decisions  about  how  the  future  should  look. 

b.  Capability  tends  to  be  enduring  and  therefore  the  modelling  work  is  likely  to  be 
carried  forward  in  the  ‘To  Be’  models;  it  is  the  manner  of  delivery  and  required  levels  of 
effectiveness  that  tends  to  change  rather  than  the  capability  itself.  Even  if  the  capability  is 
to  change,  an  understanding  of  the  current  situation  will  improve  the  quality  of  decisions 
made  about  how  the  future  should  be. 

c.  The  Strategic  Views  are  also  used  to  scope  and  confirm  the  boundaries  of  the 
problem  situation  as  discussed  in  Paragraph  10. 

23.  Use  of  Strategic  Views  in  the  ‘To  Be’  Models.  The  Strategic  Views  in  the  ‘To  Be’ 
architecture  will  be  one  of  the  principle  means  of  communicating  to  the  IPT1  ^contractor  the  context 
in  which  the  delivered  system  is  to  operate,  the  military  objectives  it  is  to  support  and  the  benefit  it 
is  to  deliver.  Text  based  URDs  can  only  convey  the  ‘letter’  of  the  requirement,  whereas  the 
Strategic  Views  can  also  enable  suppliers  to  understand  the  ‘spirit’  of  the  requirement  and  to  ask 
more  informed  questions.  Any  system  design  should  be  considered  against  these  models,  to  ensure 
it  contributes  to  the  overall  capability  in  the  manner  intended. 

OPERATIONAL  VIEWS. 

24.  The  Operational  Views  (OV)  are  a  description  of  the  organisations11,  activities,  and 
information  exchanges  required  for  a  particular  military  mission  or  business  need.  OVs  are  likely  to 
be  produced  for  a  range  of  scenarios,  as  the  interaction  between  organisations  and  process  may 
vary,  dependant  on  the  mission  and  environment.  The  OVs  provide  an  increasing  level  of  detail 
ranging  from  the  high  level  context  diagram  (20,000  ft  view  of  the  Capability  -  the  “PowerPoint 
view”)  to  the  full  operational  activity  model. 

25.  Overview  of  Operational  Views.  The  total  set  of  operational  views  consists  of: 

•  High-Level  Operational  Concept  Graphic  (OV-1):  An  overview  graphic. 

•  Organisation  Connectivity  Model  (OV-2):  A  description  of  how  organisations  interact. 

•  Information  Exchange  Matrix  (OV-3):  A  table  of  information  exchanged  between 
organisations. 

•  Organisation  Relationship  Diagram  (OV-4):  A  command  relationship  ‘wiring  diagram’. 

10  Under  SAMRT  procurement,  projects  are  delivered  (and  managed  through  life)  by  Integrated  project  Teams  (IPT). 

1 1  Formally  referred  to  as  operational  nodes.  The  models  can  contain  organisations,  sub  units,  roles,  actors  and  or  informal  groupings. 
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•  Operational  Activity  Model  (OV-5):  Process  models. 

•  Operational  Activity  Sequence  and  Timing  Descriptions  (OV-6,  OV-a,  OV-b,  and  OV-c):  A 
description  of  behaviour  over  time. 

•  Logical  Data  Model  (OV-7):  A  description  of  the  nature  of  the  information  and  its  attributes. 

The  Command  Relationships  (OV-4)  may  provide  useful  background  information  to  a  contractor, 
but  do  not  directly  inform  the  requirements,  and  hence  are  not  addressed  in  this  paper.  Equally,  the 
Activity  Sequence  views  (OV-6)  may  have  a  part  to  play  in  developing  user  requirements,  but  that 
aspect  has  not  yet  been  developed  fully. 

26.  High  Level  Operational  Representation  OV-1.  The  OV-1  should  not  be  mistaken  with  the 
strategic  views,  but  often  is.  It  is  essentially  a  high-level  briefing  or  marketing  tool.  Whilst  it  can 
be  used  to  focus  detailed  discussions,  the  Strategic  Views  are  more  suited  to  this  purpose.  An 
important  point  to  note  is  that  everything  that  appears  in  the  OV-1  should  be  present  in  the  main  set 
of  MODAF  views.  It  is  recommended  that  the  OV-1  be  produced  as  a  summary  of  the  modelling, 
not  the  starting  point. 

a.  Use  of  OV-1  in  ‘As  Is’  Models.  The  OV-1  is  probably  not  required  in  the  ‘As  Is’ 
models,  unless  a  briefing  tool  is  required  above  and  beyond  that  provided  by  the  Strategic 
Views. 

b.  Use  of  OV-1  in  ‘To  Be’  Models.  Produced  as  a  briefing  tool,  the  OV-1  is  a  useful 
aid  when  ‘selling’  the  proposed  application  to  the  user  community  and  senior  officers. 

27.  Organisational  Interconnectivity  OV-2.  The  OV-2  identifies  relevant  organisations  and  the 
relationships  between  them  in  terms  of  the  need  to  exchange  information.  The  OV-2  is  essential  to 
understand  the  organisational  boundaries,  identify  the  potential  customers,  and  make  explicit  their 
relationship  with  each  other  in  terms  of  information  exchange.  Having  identified  a  need  to 
exchange  information  the  nature  of  the  information  being  exchanged  can  then  be  identified  and 
articulated.  Views  may  contain  either  organisations  or  roles,  but  it  is  recommended  not  to  mix  the 
two  in  the  same  model.  The  example  in  Figure  1  is  a  simple  organisational  connectivity  model,  in 
which  the  lines  represent  information  exchanges  and  the  labels  on  the  lines  indicate  the  type  of 
information  being  exchanged.  The  view  also  allows  (not  shown  in  the  example)  for  additional 
fields  such  as  ‘purpose’  to  be  defined  against  each  organisation. 

a.  Use  of  the  OV-2  in  ‘As  Is’  Modelling.  The  ‘To  Be’  views  identify  the  organisations 
involved  in  the  relevant  area  of  operations  at  the  current  time.  It  offers  the  first  opportunity 
to  identify  the  high  level  IERs,  and  confirms  the  organisational  boundary  of  the  situation 
under  investigation.  The  level  of  modelling  has  to  be  carefully  considered  to  avoid  nugatory 
work  where  the  organisations  may  be  subject  to  change.  In  general,  the  modelling  will  be 
limited  to  the  Unit/Sub  unit  level,  although  each  situation  will  vary. 

b.  Use  of  the  OV-2  in  ‘To  Be’  Modelling.  The  ‘To  Be’  models  are  likely  to  be 
developed  in  more  depth.  They  convey  to  the  contractor  who  needs  to  do  what,  and  what 
their  IERs  will  be.  They  may  well  show  individual  roles  or  staff  branches.  Other 
constraints  and  factors  may  be  shown  against  organisations  or  the  information  exchanges 
between  them,  conveying  to  the  supplier12  a  richer  picture  of  the  requirement.  For  example, 
geographical  or  operational  requirements  that  apply  to  only  some  of  the  organisations,  such 
as  the  need  to  deploy  as  airborne  forces,  can  be  shown  against  each  relevant  organisation 


12  Both  the  IPT  and  the  Contractor 
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28.  Process  Models  OV-5.  The  purpose  of  OV-5  models  is  to  express  the  military  business 
processes  intrinsic  to  achieving  the  operational  aim.  As  discussed  in  Paragraph  15,  care  must  be 
taken  to  avoid  inadvertently  imposing  constraints  by  detailing  processes  to  operate  the  IS  itself  as 
oppose  to  achieving  the  business  aim.  A  full  and  shared  understanding  of  business  processes  is 
essential  to  developing  URs.  Whilst  the  Armed  forces  are  very  good  at  doing  what  they  do,  they  are 
not  so  good  at  communicating  clearly  and  meaningfully  what  it  is  that  they  do.  Equally,  many 
requirements  span  a  significant  scope  of  activities,  and  users  rarely  have  a  clear,  comprehensive  and 
up  to  date  understanding  of  how  the  entire  business  operates.  OV-5  models  offer  a  means  of 
communicating  processes  in  a  manner  that  is  meaningful  to  both  the  military  and  suppliers  alike. 
Processes  are  performed  by  organisations.  The  modelling  tool  set  is  used  to  associate  organisations 
created  in  the  OV-2  with  activities  in  the  OV-5.  Just  as  organisations  have  IERs,  so  do  activities. 
Once  the  activities  are  articulated,  the  full  IERs  that  support  them  can  be  created  and  associated 
with  the  process  model.  Identifying  IERs  for  both  the  organisations  that  perform  activities  and  the 
activities  themselves  provides  a  cross  check  to  ensure  that  all  relevant  IERs  have  been  identified. 
Use  of  an  object  based  modelling  tool  enables  the  IER  to  be  created  once  and  used  in  both  views. 

a.  Use  of  OV-5  in  ‘As  Is’  Models.  The  ‘As  Is’  process  views  are  used  primarily  to 
understand  how  the  business  operates  currently,  in  order  that  development  of  the  future 
processes  is  informed  by  knowledge  of  the  past.  More  emphasis  should  be  placed  on 
understanding  the  intent  of  the  processes,  than  should  be  placed  on  understanding  the  detail 
of  what  is  done  (although  the  later  may  be  necessary  to  fully  understand  the  intent).  Again, 
careful  consideration  is  required  to  avoid  modelling  non-enduring  processes  below  a  level  of 
detail  that  serves  the  purpose  of  aiding  discussions  about  the  future. 

b.  Use  of  OV-5  in  ‘To  Be’  Models.  The  ‘To  Be’  OV-5  models  are  the  primary  set  of 
models  that  will  describe  the  functional  requirements  of  the  system  and  the  military 
processes  with  which  it  is  to  operate.  Great  care  must  be  taken  to  only  show  what  is  to  be 
achieved,  without  inadvertently  constraining  potential  solutions  (solutioneering).  The 
modelling  will  start  with  the  processes  that  are  required  throughout  the  area  of  operations 
under  investigation,  but  should  then  make  explicit  those  processes  that  are  to  be  delivered  or 
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directly  supported  by  a  particular  programme  or  project.  The  models  should  show 
increasing  fidelity,  until  each  object  with  a  model  represents  an  atomic  functional  UR. 


Figure  2:  Example  of  an  OV-5  Process  Model 


29.  Information  Exchange  Requirements  OV-3.  The  OV-3  shows  the  information  categories 
being  passed  between  organisations  during  the  conduct  of  activities.  It  is  used  to  convey  who 
exchanges  what  information,  with  whom,  why  it  is  necessary  and  how  it  is  done.  It  may  also 
contain  more  detail  about  the  information  that  supports  the  process.  It  is  not  a  model  in  its  own 
right  and  does  not  contain  any  information  not  held  in  other  operational  views.  It  is  a  report 
summarising  the  IERs  derived  in  the  organisational  connectivity  models  (OV-2)  and  activity 
models  (OV-5),  possibly  with  additional  information  gleaned  from  the  Logical  Data  Model  (OV-7). 
The  utility  of  the  view  is  the  focus  it  provides  on  information  categories. 


Simplified  Example  of  Information  Exchange 
Requirement  Matrix  (OV-3) 


Activity 

Information 

Exchanged 

Format 

Source  Node 

Destination 

Node 

Security 

Classification 

Criticality 

Frequency 

A 

Orders 

Text 

One 

Two 

S 

High 

Event 

driven 

B 

Coord  Info 

Formatted 

R3 

Two 

Three 

R 

Routine 

Daily 

D 

Planning  Info 

Text  & 

R3 

Three 

Two 

S 

High 

Daily 

Figure  3:  Example  of  an  OV-3 
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a.  Use  of  OV-3  in  ‘As  IS’  Models.  The  OV-3  focuses  on  information  categories  and  as 
such  could  be  used  to  cross  check  against  known  IERs  for  other  systems  (existing  and 
planned)  in  order  to  identify  potential  overlaps  or  to  make  decisions  relating  to  the 
apportionment  of  work  to  appropriate  systems,  organisations  or  personnel.  Generally,  it 
should  not  be  used  as  the  primary  document  presented  to  users  when  asking  them  to  confirm 
that  all  IERs  have  been  identified;  the  graphical  representations  used  in  the  organisational 
connectivity  (OV-2)  and  activity  (OV-5)  views  are  far  better  suited  to  this  purpose. 

b.  Use  of  OV-3  in  ‘To  Be’  Models.  The  focus  on  information  categories  provided  by 
the  OV-3  may  be  used  in  conjunction  with  the  Logical  Data  Model  (OV-7)  to  identify 
information  based  URs. 

30.  Information  Model  Using  CBML  (Description  of  the  Information  Used)  OV-7.  OV-7  is  a 
view  defined  in  DODAF  as  the  Logical  Data  Model.  One  of  the  problems  with  Logical  Data 
Models  is  that  they  do  not  enable  a  business  to  describe  the  information  that  is  important  to  it, 
without  also  describing  the  structure  of  the  data.  Descriptions  of  data  structure  (and  hence  Logical 
Data  Models)  are  more  appropriate  to  System  Requirements  and  System  Design  than  to  User 
Requirements,  where  a  more  simple  view  of  information,  independent  of  implementation  issues,  is 
required,  for  this  reason  D  CBM(A)  has  developed  Corporate  Business  Modelling  Language 
(CBML),  which  enables  the  business  to  describe  the  nature  of  the  information  used  in  the  IERs 
identified  from  the  organisational  (OV-2)  and  activity  (OV-5)  views  and  listed  in  the  Information 
Exchange  Requirement  (OV-3).  It  is  proposed13  that  MODAF  Operational  View  -7  (OV-7) 
recommends  the  use  of  both  Information  Models  (in  the  form  of  CBML)  and  Logical  Data  Models. 
Information  Models  should  be  used  at  the  business  end  of  the  development  spectrum  and  Logical 
Data  Models  at  the  Technical  end  of  the  development  spectrum.  CBML  Information  Models  enable 
subject  matter  experts  to  understand  and  confirm  the  nature  of  information  used  in  the  Logical  Data 
Models  (which  should  be  developed  to  support  the  System  Requirements  and  Design),  without 
confronting  them  with  the  complexity  of  Logical  Data  Models  themselves.  The  example  in  Figure 
4  describes  two  ways  of  categorising  bridges  by  design  type:  arched  and  military  pontoon. 


Figure  4:  Example  of  CBML  OV-7  model 


13  The  decision  has  not  yet  been  made.  Information  Models  may  become  a  sub  category  such  as  OV-7a. 
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a.  Use  of  the  Information  Model  (OV-7)  in  ‘As  Is’  Models.  The  Information  Model  is 
used  to  identify  and  communicate  the  nature  of  the  information  that  the  potential  system  is 
concerned  with.  The  models  must  provide  sufficient  understanding  of  the  nature  of  the 
information  to  ensure  that  proposed  future  processes  and  organisations  are  coherent  with 
information  requirement. 

b.  Use  of  the  Information  Model  (OV-7)in  ‘To  Be’  Models.  The  level  of  detail  must  be 
sufficient  that  when  the  contractor  provides  the  means  to:  capture,  manage  and  distribute  the 
information  described  in  the  Logical  Data  Model  (OV-7);  to  meet  the  processes  described  in 
the  OV-5;  and  the  organisational  structure  described  in  the  OV-2;  then  the  business  need 
will  be  met  in  full.  Understanding  and  articulating  the  full  nature  of  information  to  be  input, 
manipulated  and  output  from  a  system  is  the  one  of  the  most  critical  aspects  to  achieving 
project  success.  Failure  in  this  respect  can  lead  to  significant  project  problems  and  may 
result  in  the  information  system  not  providing  the  anticipated  benefit  to  military  capability. 

SYSTEM  VIEWS 

3 1 .  System  Views  describe  existing  and  proposed  information  systems,  their  interconnections 
and  functions.  They  are  primarily  used  during  system  design  rather  than  user  requirement 
development  but  they  do  have  their  place  in  eliciting  valid  business  constraints  upon  a  set  of 
requirements.  In  the  Network  Enabled  Capability  (NEC)  era  where  capability  is  delivered  through 
a  System  of  Systems  (SoS)  there  are  genuine  system  constraints  that  need  to  be  expressed.  This  is 
not  ‘solutioneering’  but  an  essential  aspect  of  achieving  a  coherent  System  of  Systems.  For 
example  it  may  be  quite  valid  for  an  application  intended  for  use  by  a  deployed  Battle  Group  to 
dictate  that  it  must  be  able  to  use  the  Bowman  radio  system  as  a  data  bearer.  Bespoke  hardware 
may  be  the  optimum  for  the  application,  but  the  field  force  cannot  support  a  plethora  of  hardware 
infrastructures.  The  primary  views  used  in  the  UR  development  process  are: 

•  Systems  Interface  Description  (SV-1).  A  Model  of  discrete  information  systems  and  how 
they  interact. 

•  Systems  Communications  Description  (SV-2).  A  model  of  the  communication  systems  used 
to  provide  system  connectivity. 

•  Systems  Functionality  Description  (SV-4).  A  description  of  the  functions  of  systems. 

•  Operational  Activity  to  Systems  Functionality  Traceability  Matrix  (SV-5).  A  mapping  of 
business  process  to  Application  functions. 

32.  Systems  Interface  Description  SV-1.  The  systems  interface  view  depicts  information 
systems  that  exist  at  organisational  nodes,  and  the  interconnection  between  those  systems.  It  acts  as 
a  link  between  the  operational  views  and  system  views,  by  showing  IS  against  the  organisations 
depicted  in  the  Operational  Interconnectivity  Models  (OV-2).  An  example  SV-1  is  shown  in 
Figure  5.  Its  primary  purpose  in  the  UR  process  is  to  highlight  other  IS  that  various  organisations 
may  have  (now  or  in  the  future)  in  order  to  identify  business  constraints  upon  the  system.  For 
example,  if  it  is  decided  that  an  application  must  be  hosted  on  BOWMAN  but  organisations 
depicted  in  the  OV-1  are  outside  the  BOWMAN  lay  down,  then  the  System  Interface  Description 
SV-1  will  indicate  a  requirement  to  host  the  application  beyond  the  existing  BOWMAN 
infrastructure. 
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Figure  5:  Example  of  an  SV-1  Systems  Interface  Description 


33.  Systems  Communications  Description  (SV-2).  The  SV-2  view  depicts  the  methods  of 
communications  used  to  implement  the  interfaces  depicted  in  SV-1.  Again  it  is  used  to  understand 
and  articulate  the  business  constraints  relating  to  communications.  An  example  of  an  SV-2  is 
shown  in  Figure  6. 


Figure  6:  Example  of  SV-2  Systems  Communications  Model 


34.  Systems  Functionality  Description  (SV-4).  The  SV-4  view  is  used  to  understand  the 
functions,  hierarchies  and  data  flows  of  existing  and  proposed  IS.  It  is  used  to  understand  what 
parts  of  the  required  processes  are  already  covered  by  other  IS  in  order  to  make  informed  decisions 
about  business  constraints  or  opportunities.  It  may  also  be  used  to  inform  investment  appraisal 
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decisions.  There  are  a  number  of  formats  that  could  be  used  for  this  view,  but  which  ever  is  chosen 
should  facilitate  a  mapping  between  the  System  Functional  Descriptions  (SV-4)  and  the  Operational 
Activity  Models  (OV-5)  in  order  to  understand  how  the  requirement  is  met  by  other  IS. 

35.  Operational  Activity  to  Systems  Functionality  Traceability  Matrix  (SV-5).  The  SV-5 
provides  a  mapping  between  the  functions  performed  by  other  IS  and  the  required  processes 
depicted  in  the  activity  models  (OV-5).  It  is  likely  that  there  will  not  be  an  obvious  one  to  one 
mapping  between  the  System  Functionality  Description  (SV-4)  and  the  process  models  (OV-5s); 
they  may  be  produced  to  different  levels  of  detail  or  structured  differently.  Where  this  is  the  case 
the  Traceability  Matrix  (SV-5)  makes  the  mapping  clear. 

CONSTRUCT  THE  URD 


36.  Users’  requirements  will  be  derived  using  a  number  of  techniques,  of  which  architectural 
modelling  using  MODAF  as  the  framework  is  only  one,  albeit  the  major  source.  The  following 
section  describes  how  use  of  MODAF  products  contributes  to  development  of  the  URD. 

PART  1:  GENERAL  DESCRIPTION 

37.  The  Part  1  of  the  URD  is  intended  to  provide  an  introduction  and  context.  It  should  not  be 
used  to  convey  requirements  as  such,  although  it  may  reflect  (duplicate)  requirements  that  are 
expressed  explicitly  in  more  detail  in  later  sections.  The  various  elements  of  Part  1  are  informed 
by,  or  derived  from,  the  Strategic  Views.  It  will  also  be  informed  by  capability  themes  such  the 
Defence  Capability  Framework  (DCF),  enduring  tasks  such  as  the  Mission  Essential  Task  Lists 
(METLs),  and  explicit  business  knowledge  such  as  doctrine  or  lessons  learnt.  However, 
comprehensive  Strategic  Views  will  contain  such  information,  and  should  prove  to  be  a  more 
readily  digestible  format.  The  main  sources  for  the  various  elements  of  Part  1  are  shown  below: 


Serial 

Section  Heading 

Informed  by 

(a) 

(b) 

(c) 

1. 

Introduction 

StV-1  Capability  Vision 

StV-2  Capability  Functions 

2. 

Background 

StV-1  Capability  Vision 

StV-2  Capability  Functions 

StV-4  System  of  System  Clusters 

3. 

Single  Statement  of  User  Need 

4. 

System  Owned/Operated  By 

StV-2  Capability  Functions 

5. 

To  do  p 

StV-2  Capability  Functions 

StV-5  Capability  to  System  Deployment 
Mapping 

6. 

By  doing  q 

StV-2  Capability  Functions 

StV-5  Capability  to  System  Deployment 
Mapping 

7. 

In  order  to  do  r 

StV-1  Capability  Vision 

StV-2  Capability  Functions 

8. 

Within  Constraints 

StV-1  Capability  Vision 

9. 

Required  Operationally  Available  Date 

StV-3  capability  Phasing 

10. 

Operational  Context 

StV-1  Capability  Vision 

StV2  Capability  Functions 

Doctrine  and  DCF 

11. 

Assumptions  and  Dependencies 

TBD 
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PART  2:  KEY  USER  REQUIREMENTS  (KURS) 


38.  Key  User  Requirements  (KUR)  are  simply  those  requirements  expressed  in  Part  3  that  are 
deemed  key  to  the  capability  to  be  delivered.  The  deletion  or  dilution  of  a  KUR  is  likely  to  have  a 
serious  and  immediate  impact  on  the  ability  of  the  project  to  deliver  the  expected  benefit  as 
described  by  the  URD  and  any  associated  business  case.  The  prioritisation  of  the  URs  is  informed 
mainly  by  the  Capability  Vision  and  Functions,  and  to  a  lesser  extent  the  other  Strategic  Views. 
The  Operational  Views  will  further  influence  prioritisation. 

PART  3:  USER  REQUIREMENTS  £UR) 

39.  The  Part  3  contains  the  actual  user  requirements.  The  headings  in  a  URD  vary  depending 
upon  the  author,  but  Reference  A  recommends  the  following  (details  of  which  are  contained  in 
Reference  A): 


a.  Unique  Ref  Number:  An  enduring  number  that  remains  constant  throughout  all 
versions  of  a  URD. 

b.  UR  Title:  A  short  description. 

c.  User  Ability:  A  more  detailed  explanation  of  the  requirement. 

d.  Context:  A  description  of  the  situation  that  the  UR  is  aiming  to  improve  or  support. 

e.  Effectiveness  Envelope:  A  numerical  quantifier  of  how  well  the  UR  has  to  perform 
its  task.  Normally  expressed  in  terms  of  Stretch  (ideal).  Plan  (minimum  standard  required), 
and  Now  (how  well  its  currently  performed).  At  the  User  level,  they  should  be  expressed  in 
terms  of  the  higher-level  goals,  not  specific  functions.  For  example  the  user  should  only  be 
concerned  with  how  long  it  takes  from  identifying  a  target  to  rounds  hitting  it.  EEs  about 
parts  of  that  process  are  the  domain  of  the  system  requirements,  not  user  requirements. 

f.  Owner:  The  person  responsible  for  defining  and  amending  a  UR.  Can  also  include 
the  organisations  directly  effected  by  the  UR. 

g.  Justification:  Why  the  UR  is  required. 

h.  Verification:  Every  UR  must  have  a  means  of  verifying  that  it  has  been  met. 
Although  it  is  common  to  state  the  type  of  test  such  as  Field  Trial,  it  is  more  helpful  to 
describe  the  degree  of  achievement  that  will  constitute  compliance.  For  example  “The 
system  shall  display  x  during  an  Armoured  Brigade  CPX.” 

i.  Priority:  The  priority  of  the  UR  expressed  as  one  of  4  priorities: 

(1)  Key:  Essential.  Without  it  there  is  no  capability. 

(2)  Priority  1 :  Highly  desirable 

(3)  Priority  2:  Desirable 

(4)  Priority  3:  Nice  to  have. 

URs  are  traditionally  split  into  functional  and  non-functional  requirements. 

40.  Functional  Requirements.  The  Operational  Activity  Models  (OV-5)  should  lead  to  a 
structuring  of  functional  requirements  that  make  them  digestible  in  readily  understood  chunks. 
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D  CBM(A)  Requirements  group  contend  that  functional  requirements  for  an  information  system 
take  one  of  3  basic  forms14:  process  based  requirements,  information  exchange  based  requirements 
and  requirements  about  how  the  user  wishes  the  future  system  to  support  the  business  derived  from 
assumptions  about  that  future  system. 

a.  Process  based  URs.  The  primary  type  of  functional  requirements  are  process  based 
i.e.  “the  User  shall  be  able  to  do  something”.  The  Operational  Activity  (OV-5)  4To  Be’ 
models  should  clearly  articulate  what  the  processes  are  that  the  business  need  to  conduct  in 
order  to  deliver  the  required  capability.  Within  any  military  capability  area,  a  particular 
information  system  project  will  only  deliver  part  of  the  capability.  Whilst  the  whole 
capability  should  be  modelled  to  varying  degrees  of  granularity  in  order  to  convey  the 
context,  the  Operational  Activity  models  should  make  explicit  those  process  that  are  (and 
those  that  are  not)  to  be  delivered  by  the  project.  Such  processes  should  be  decomposed  to  a 
point  where  each  atomic  requirement  in  the  URD  is  represented  by  one  activity  in  an  OV-5 
model.  The  fields  are  derived  in  the  following  manner  and  shown  graphically  in  Figure  7: 

(1)  UR  title:  Taken  directly  from  the  object  in  the  OV-5. 

(2)  User  Ability:  Articulated  in  a  memo  field  in  the  OV-5  for  each  object  that  is 
to  provide  a  UR  for  the  project. 

(3)  Context:  A  textual  summary  of  how  the  UR  contributes  to  the  wider  process. 
The  information  is  derived  manually  from  understanding  the  agreed  set  of  OV-5s. 

(4)  Effectiveness  Envelopes  (EE):  The  method  of  expressing  EEs  within 
MODAF  products  has  not  yet  been  fully  confirmed,15  however  the  Strategic  Views 
and  the  OV-5  process  models  will  enable  individual  EEs  be  expressed  and  justified 
in  terms  of  higher  level  goals  and  process  requirements. 

(5)  Justification:  The  importance  of  the  process  to  the  whole  process  and  higher 
level  goals  can  be  seen  by  understanding  the  Strategic  Views  and  the  OV-5  process 
models.  The  justification  field  should  commence  with  a  numerical  reference  to  the 
model(s)  from  which  the  UR  was  derived. 

(6)  Verification:  MODAF  says  nothing  about  how  the  test  may  be  performed, 
but  the  pass  criteria  can  be  derived  from  the  subsequent  processes  in  the  OV-5  that 
are  dependent  upon  the  process  from  which  the  UR  was  derived. 

b.  Information  Based  URs.  The  nature  of  the  information  to  be  input  to,  used  by  and 
output  from  various  processes  is  critical  to  the  system  delivering  the  required  capability  at 
the  required  place  and  time.  The  full  nature  of  all  the  relevant  information  will  be  described 
using  CBML  in  the  Logical  Data  Model  (OV-7).  However,  there  will  often  be  value  in 
verbalising  the  CBML  and  including  it  in  the  URD  to  describe  the  nature  of  the  information 
used  by  a  single  process  or  group  of  processes.  Alternatively  URs  will  refer  directly  to  the 
Logical  Data  Model. 

c.  Derived  URs.  When  articulating  user  requirements  it  is  not  uncommon  to  encounter 
a  number  of  URs  that  are  difficult  to  categorise  as  either  functional  or  non- functional.  This 
can  be  due  to  requirements  that  are  derived  from  reasonable  assumptions  made  about  the 
system  that  will  be  delivered.  For  example  ‘the  user  shall  be  able  to  define  the  percentage 


14  They  are  unlikely  to  appear  as  group  heading  in  a  URD,  but  are  used  to  understand  the  nature  of  functional  requirements,  with  all  3  types  being 
intermingled  in  a  URD. 

15  Future  development  may  lead  to  qualities  being  shown  against  specific  elements  of  the  models,  which  are  then  used  as  effectiveness  envelopes. 
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battery  level  at  which  a  warning  is  given  The  enterprise  does  not  have  a  business 
requirement  to  have  batteries,  rather  a  reasonable  assumption  is  made  that  the  solution  may 
involve  a  computer  and  therefore  it  may  have  batteries  and  therefore  a  user  definable 
warning  is  required.  Although  this  might  strictly  be  a  system  requirement,  it  is  something 
that  the  user  is  concerned  with,  and  hence  maybe  a  valid  user  requirement.  For  the  purposes 
of  this  paper,  such  URs  will  be  referred  to  as  ‘derived  requirements’. 


41.  Non-Functional  Requirements.  Non-functional  requirements  should  describe  the  required 
characteristics  of  the  system,  and  perhaps  more  importantly  the  business  constraints  that  should  be 
applied  to  it.  It  has  been  a  tenet  of  SMART  procurement  that  best  value  for  money  is  achieved  by 
giving  IPTs  complete  freedom  of  action.  Flowever,  as  the  “Nash  Equilibrium”  (Nash:  1950)  makes 
clear,  mutual  benefit  is  not  maximised  through  each  group  (IPT  in  acquisition  terms)  doing  just 
what  is  best  for  itself,  but  also  what  is  best  for  the  business  as  a  whole.  In  other  words  groups  have 
to  balance  what  is  best  for  them  against  what  may  be  best  for  the  business  as  a  whole.  Sub¬ 
optimised  parts  may  be  necessary  to  achieve  the  optimum  whole.  Hence,  an  expression  of  business 
constraints  and  opportunities  for  cross  system  rationalisation  is  essential  to  achieving  a  coherent, 
affordable  and  effective  SOS.  The  Strategic,  Operational  and  System  views  offer  a  means  by  which 
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capability  working  groups  can  understand  the  SOS  constraints  and  opportunities  for  cross  system 
rationalisation.  The  decisions  made  by  the  Working  Groups  should  be  expressed  as  non- functional 
requirements,  making  clear  the  difference  between  opportunities  and  desirable  or  mandatory 
constraints.  Such  URs  should  refer  to  the  MODAF  models  from  which  they  were  derived/justified. 

42.  Non-Functional  Requirements  by  Lines  of  Development.  The  most  significant  proposed 
change  to  non- functional  requirements  is  the  intention  to  include  a  section  on  each  Line  of 
Development  (LOD).  Traditionally,  the  URD  is  a  statement  of  requirement  for  the  equipment  line 
of  development,  however  “information  systems  are  not  equipment  programmes,  but  business 
programmes  enabled  by  technology”  (McCartney:  2000).  Furthermore,  the  IPT  Team  Leader  now 
has  single  point  responsibility  for  ensuring  that  all  lines  of  development  are  delivered.  Including  all 
LOD  in  the  URD  ensures  that  a  statement  of  requirement  for  the  whole  project  is  brought  together 
in  the  one  document  that  the  user  community  (Customer  2  as  well  as  Customer  1)  has  the  most 
involvement  in.  The  URs  for  each  line  of  development  will  state  what  needs  to  be  achieved  in 
order  to  deliver  the  capability. 

a.  Concepts  and  Doctrine.  The  URD  should  contain  high-level  statements  outline 
changes  required  to  Concepts  and  Doctrine  (C&D).  Ideally,  the  capability  audit  and 
resultant  system  definition  should  be  conducted  and  defined  against  agreed  and  published 
C&D.  However,  IS  projects  often  either  precede  formal  C&D,  or  they  impact  on  other  areas 
of  it.  An  example  is  the  Recognised  Theatre  Logistic  Picture:  Logistic  C&D  is  documented 
in  Joint  Warfare  Publication  (JSP)  04.  However,  the  current  version  only  mentions  the 
RTLP  very  briefly  despite  it  having  a  significant  impact  on  the  way  logistics  will  be 
conducted  in  the  future.  The  URD  for  any  project  delivering  elements  of  the  RTLP  should 
therefore  articulate  a  project  dependency  on  changing  JWP  04. 

b.  Equipment.  The  Equipment  LOD  is  addressed  by  the  URD  in  its  traditional  form. 

c.  Training.  Training  is  one  of  the  most  challenging  LODs  in  Digitisation.  The  URs 
must  not  only  express  the  requirements  to  achieve  a  trained  workforce,  but  also  convey 
sufficient  business  constraints  to  ensure  the  field  force  are  able  to  cope  with  the  training 
burden  imposed.  The  strategic  views,  particularly  the  Capability  Functions  (StV-2),  made  in 
light  of  the  system  groupings  identified  in  the  System  of  Systems  Clusters  (StV-4),  will 
highlight  the  opportunities  for  rationalising  training.  The  various  StVs  should  be  used  to 
express  to  the  Front  Line  Commands  the  potential  training  burden  for  the  whole  of  a 
capability,  thus  enabling  them  to  express  business  constraints  on  training,  which  can  then  be 
articulated  as  URs.  Consideration  needs  to  be  given  to  methods  of  modelling  training 
requirements  and  associating  them  with  the  applications  and  SOS  clusters  they  support. 

d.  Structures.  The  differences  in  the  Organisational  Views  (OV-2)  articulated  in  the 
‘As  Is’  and  ‘To  Be’  models  will  indicate  the  changes  required  to  structures.  Those 
requirements  for  change  should  be  expressed  as  URs  where  possible. 

e.  Sustainability.  Sustainability  is  partially  covered  by  the  Availability  and 
Administration  sections  in  a  traditional  URD.  However,  the  SOS  aspect  of  NEC  means  that 
URs  for  a  particular  system  need  to  identify  business  constraints  to  ensure  the  delivered 
solution  is  the  most  efficient  for  the  business  as  a  whole,  and  not  just  the  system  in  question. 
Sustainability  is  influenced  by  3  major  factors: 

(1)  Availabilitv/Operational  Criticality.  The  availability  required  should  be 
derived  from  the  system’s  criticality  to  operations.  The  combination  of  the  Strategic 
Views,  OV-5  (process  models)  and  System  Views  should  inform  the  discussion  as  to 
what  availability  is  required  in  terms  of  operational  criticality.  The  URs  should  refer 
to  the  models  as  justification  for  the  requirements. 
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(2)  SOS  Administration  Capability.  The  requirement  to  use  common 
administration  resources  across  systems  could  be  considered  a  design  solution  and 
therefore  outside  of  the  remit  of  a  URD.  However,  if  it  is  considered  to  be  a  valid 
business  constraint  (and  it  probably  should  be)  then  it  should  be  expressed  in  the 
URD.  This  decision  should  be  taken  by  a  pan-system  working  group,  informed  by 
the  various  system  MODAF  models. 

(3)  Phasing  of  Systems.  Decisions  about  SOS  administration  should  be 
informed  by  the  phasing  of  SOS  delivery,  expressed  in  the  Capability  Phasing  (StV- 
3)  models. 

f.  People.  The  People  LOD  introduces  valid  business  requirements.  Influences  on  the 

people  LOD  are  not  currently  expressed  in  MODAF  models  other  than  in  the  OV-2  models. 

Their  impact  on  the  URD  has  yet  to  be  considered. 

INCORPORATING  USER  REQUIREMENTS  INTO  THE  ARCHITECHTURE 

43.  MIDAS  is  an  implementation  of  the  MODAF  framework  in  the  MooD  Transformation 
Toolset  (a  modelling  application),  which  D  CBM(A)  uses  to  develop  MODAF  compliant 
architectures.  D  CBM(A)  has  now  incorporated  user  requirements  into  the  MooD  Integrated 
Defence  Architecture  Solution  (MIDAS)  VI. 2.  The  intention  is  to  retain  a  URD  format  as  a 
standalone  MS  Word  document  or  a  DOORS  database  but  in  the  future  these  documents  will  be 
produced  as  an  export  from  an  architecture  that  contains  the  URs.  The  URs  will  be  derived  from, 
and  referenced  to,  the  other  elements  within  the  architecture  using  the  methodology  described  in  the 
previous  two  sections.  Incorporating  the  URs  into  the  architecture  from  which  they  were  derived 
presents  a  number  of  opportunities,  the  most  significant  of  which  are  described  below. 

44.  Improved  Understanding.  The  references  between  URs  and  elements  of  the  architectures 
that  informed  them,  improves  understanding  by  providing  the  background  and  context  that  led  to 
the  requirement.  This  in  turn  reduces  the  number  of  unintended  constraints  by  providing  suppliers 
with  the  information  that  enables  them  to  ask  more  relevant  and  informed  questions.  It  is 
recommended  that  the  architecture  that  led  to  a  URDs  is  supplied  to  industry  along  with  the  URD 
itself. 

45.  Assessment  Gaps.  Architectures  are  intended  to  provide  a  visual  representation  of  the 
entire  military  business  under  consideration,  which  as  stated  earlier,  should  enable  subject  matter 
experts  to  confirm  that  a  subject  has  been  covered  comprehensively.  The  functionality  provided  by 
architecture  modelling  tools  (such  as  MooD)  facilities  easy  cross  checking  between  a  URD  and  the 
architecture  to  ensure  that  a  set  of  URs  provide  comprehensive  coverage  of  a  specified  area,  as 
defined  by  the  architecture. 

46.  Assessment  of  Coherence.  D  CBM(A)  has  now  developed  a  tool  called  rCAT  in  partnership 
with  Hi-Q  Systems.  rCAT  exploits  the  relationships  between  URs  and  other  elements  in  an 
architecture  to  assess  coherence  between  URs  within  a  single  set  (one  URD)  and  between  URs  in 
different  projects.  The  coherence  is  expressed  in  terms  of  potential  overlaps  and  inconsistencies 
between  URs  related  to  common  elements  of  the  architecture  and  is  based  on  analysis  of  direct  and 
indirect  relationships  expressed  in  the  architecture.  The  tool  also  facilities  the  production  of 
MODAF  compliant  process  models  from  existing  URDs  (imported  from  MS  Word  or  DOORS)  and 
suggests  relationships  between  those  new  processes  and  existing  architecture  elements.  As  a  result 
the  rCAT  tool  provides  a  powerful  means  of  assessing  the  coherence  between  the  User 
Requirements  of  existing  and  potential  projects  within  the  MoD’s  System  of  Systems.  All  results  of 
the  analysis  can  output  to  simple  reports,  for  further  consideration  by  project  staff  and  subject 
matter  experts.  For  further  details  on  rCAT,  contact  the  Requirements  Group  in  Capability 
Integration,  D  CBM(A). 
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FUTURE  DEVELOPMENT 


47.  The  MODAF  itself  is  still  being  developed,  and  its  use  to  develop  user  requirements  is 
particularly  new.  There  are  a  number  of  factors  not  yet  incorporated  into  the  use  of  MODAF,  and  it 
is  likely  that  more  will  emerge  as  experience  is  gained. 

48.  Use  of  Technical  Views  to  Support  Standards.  One  of  the  problems  with  the  use  of 
standards  in  a  URD  is  that  they  are  often  applied  in  a  broad-brush  manner  with  little  consideration 
of  the  effect  to  be  achieved  by  their  use.  The  result  is  a  stated  user  requirement  to  comply  with 
complete  standards,  not  all  elements  of  which  are  relevant  or  even  desirable.  It  is  difficult,  if  not 
impossible,  for  a  supplier  to  unequivocally  separate  from  a  URD  those  parts  of  a  standard  that  are 
desired  relevant  requirements,  and  those  parts  that  are  not  relevant  or  desired.  Equally,  standards 
are  blandly  applied  to  the  whole  URD  without  qualification,  rather  than  being  directed  at  the  URs  to 
which  they  should  apply.  Whilst  tailoring  the  use  of  standards  is,  and  should  be,  largely  the  domain 
of  the  IPT  and  the  System  Requirement  Document,  there  is  a  need  to  apply  standards  in  a  more 
qualified  and  considered  manner  at  the  User  Requirement  level.  Expressing  standards  in  technical 
views,  should  enable  agents  acting  on  behalf  of  customer  2  to: 

a.  Use  the  Standards  in  a  more  informed,  and  therefore  considered  manner. 

b.  Apply  standards  with  qualifying  statements,  thus  avoiding  unintended  consequences, 
whilst  achieving  the  desired  effect  through  the  application  of  standards 

c.  Apply  standards  in  a  more  selective  manner,  often  only  using  relevant  parts  of  a 
standard. 

The  use  of  technical  views  to  express  standards  and  associate  them  with  other  elements  of  the 
architecture  has  yet  to  be  addressed  by  D  CBM(A). 

49.  Environment.  The  military  environment  places  a  number  of  constraints  upon  individual 
requirements  and  systems  as  a  whole.  Examples  might  be  the  need  to  perform  certain  actions  in  red 
light  conditions,  or  for  certain  processes  to  be  performed  by  airborne  organisations  from  the  back  of 
a  helicopter.  Methods  of  modelling  and  therefore  understanding  and  articulating  such  constrains 
need  to  be  developed. 

50.  Location/Distance.  The  communication  requirements  for  information  exchange  are  affected 
by  location  and  distance.  This  organisation  has  not  yet  fully  considered  a  method  for  modelling  the 
requirements  related  to  location  and  distance. 

51.  Temporal  Requirements.  The  Operational  Views  include  OV-6,  OV-  6a,  OV-6b  and  OV-6c 
which  are  Activity  Sequence  and  Timing  Descriptions.  Whilst  this  is  predominantly  the  preserve  of 
the  system  engineer,  there  may  well  be  valid  user  requirements  that  should  be  borne  out  of  an 
understanding  of  timing  and  sequence.  There  are  3  types  of  temporal  consideration: 

a.  The  behaviour  of  the  processes  over  time,  i.e.  Process  A  must  be  done  within  a  day 
of  process  B.  Understanding  this  type  of  temporal  consideration  is  likely  to  improve  the 
quality  of  effectiveness  envelopes. 

b.  The  changing  nature  of  the  system  of  systems  over  months  and  years  (often  referred 
to  as  Epochs  within  digitisation.)  Links  between  MS  Project  and  the  Mood  Transformation 
Toolset  have  been  established,  although  this  work  needs  development  before  it  can  be  used 
directly  in  the  derivation  of  URs. 

c.  The  changing  nature  of  the  requirements  and  business  processes  over  time.  This 
needs  development  in  the  same  way  as  changes  in  the  system  of  systems. 
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52.  Interoperability.  Traditionally,  interoperability  is  a  stand-alone  section  in  the  Non- 
Functional  Requirements.  Whilst  this  has  value,  the  statements  are  often  very  general  in  nature,  and 
included  more  for  the  sake  of  the  approvals  process  rather  than  conveying  real  requirements  to  the 
IPT.  In  the  NEC  environment,  most  IS  will  contribute  to  and  or  be  supported  by  other  IS. 

Therefore,  it  may  be  appropriate  to  include  statements  of  interoperability  with  each  group  of 
functional  requirements. 

53.  Training/Peacetime/Exercise.  Clearly  the  field  force  spends  the  majority  of  its  time  in 
peacetime  activities,  either  in  barracks  or  on  exercise.  Whilst  any  system  has  to  be  optimised  for 
operations,  it  must  be  possible  to  use  it  in  peacetime  if  the  users  are  to  retain  training  currency  and 
hence  be  able  to  deliver  capability.  This  has  a  number  of  implications,  including  generating 
exercise/training  data  sets,  and  possibly  more  than  one  set  of  business  processes  that  have  to  be 
supported.  It  is  likely  that  the  differing  requirements  dictated  by  ‘in  barracks’,  exercise  and 
operational  activities  will  need  to  be  identified  by  developing  models  for  each  of  these  scenarios, 
however  that  has  yet  to  be  fully  considered  by  D  CBM(A). 

54.  System  Requirements.  Examination  of  system  requirements  is  largely  outside  the  remit  of 
D  CBM(A).  However,  the  principles  expressed  in  this  paper  could  be  applied  to  the  development  of 
system  requirements.  The  rCAT  toll  could  also  be  expanded  very  easily  to  assess  coherence 
between  system  requirements  within  the  System  of  Systems. 

SUMMARY 


55.  Using  MODAF  products  to  understand  capability  and  military  business  enables  User 
requirements  to  be  derived  in  a  logical  and  defensible  manner  and  expressed  in  a  richer,  yet  more 
digestible  format. 

56.  Using  the  Strategic,  Operational  and  to  a  lesser  extent  the  System  Views  the  current 
situation  can  be  fully  understood,  enabling  requirements  to  be  derived  which  better  match  the 
desired  future  military  business  and  are  more  likely  to  contribute  to  operational  capability.  The 
improved  shared  understanding  should  enable  customers  and  suppliers  to  collaborate  more 
effectively,  thus  achieving  greater  improvements  with  each  evolution  of  a  system. 

57.  Incorporating  all  Lines  of  Development  into  the  URD  places  the  emphasis  on  delivering 
capability  rather  than  just  an  equipment.  This  is  important  in  all  acquisition  projects,  but  absolutely 
critical  in  IS  projects,  which  simultaneously  enable  and  constrain  military  capability. 

58.  Incorporating  URs  into  the  architecture  from  which  they  were  derived  provides  greater 
understanding  of  the  intended  meaning  and  facilitates  extensive  analysis  of  coherence  within  the 
System  of  Systems. 


CONCLUSION 


59.  The  use  of  MODAF  products  to  derive  and  articulate  URs  needs  further  development,  but 
even  in  its  current  state  the  concept  should  be  used  as  the  basis  for  deriving  the  User  Requirements 
for  all  future  Information  Systems.  That  said,  its  use  needs  careful  consideration  and  adoption  to 
the  particular  situation  in  hand  in  order  to  achieve  the  desired  outcome.  For  that  reason,  mandating 
it  as  a  process  should  be  avoided,  as  mandation  tends  to  lead  to  blind  concentration  on  the  process 
rather  than  the  outcome. 
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•  Improved  Articulation  of  the  Requirement 

•  Communicate  the  Intended  Meaning  and  Provenance 

•  Communicate  the  Context  of  each  Requirement 

•  Inform  the  Requirement  Trading  Process 

•  Reduce  UNINTENDED  constraints 

•  Understand  the  impact  of  business  changes  on  projects 
under  development 


Enables  Analysis  of  URs  based  on  complex  relationships  - 
Requirements  Coherence  Analysis  Tool  (RCAT) 


Complex  Relationships 


ARMY 


OV-2 


OV-5 


is  performed  by 


Collate 

Intelligence 
Reports 


is  performed  by 


Analyse 

Intelligence 
Reports 


is  informed 


is  informed 


XV  -  Req 


by 


The  User 
Shall  Be  Able  To 
Collate 

Intelligence  Reports 


is  dependant 
on 


is  performed  by 
the  same 
organisation  as 


I  by 


The  User 
Shall  Be  Able  To 
Analyse 

Intelligence  Reports 


Sources  and  Types  of  Relationships 


ARMY 


•  Sources 

•  Relationships  articulated  in  the  architecture 

•  Relationships  derived  by  RCAT  analysis 
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•  MooD  Transformation  Toolset 

•  MooD  Instantiation  of  the  Defence  Architecture  Solution 
(MIDAS) 

•  Land  Environment  Command  and  Battlespace 
Management  Architecture 

•  Requirement  Coherence  Analysis  Tool 
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Summary 
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•  Requirements  Derived  from,  referenced  to  and 
stored  in  MODAF 

•  Comprehensive  Coverage  That  is 
Understandable  by  Users  and  Industry 

•  Coherence  Analysis  of  URs  based  on  complex 
relationships  expressed  in  an  Architecture 


